For example, in a system that messages are exchanged among servers in plural layers, such as an electronic commerce system, the parallel processing using plural servers is mandatory in order to a huge amount of messages at high speed. For example, FIG. 1 depicts an example of the system. Plural user terminals 3a to 3b are connected to a network 1, and furthermore, plural Web servers 61 to 64 are also connected through a distribution apparatus 51 that allocates a request from the user terminals 3a to 3b to one of the Web servers in order to realize the load distribution, to the network 1. The Web servers 61 to 64 are further connected to one or plural application servers 71 and/or one or plural DB server 81 and 83 and/or the like in the background. In such a system, for each request received by the Web servers 61 to 64, the Web server in charge of the request requests the application server 71 to execute a processing necessary for the request and obtains the processing result, and further requests the DB servers 81 and/or 83 to execute a processing to refer to and/or update the DB, which is necessary for the request, and obtains the processing results. Thus, the processing necessary for the request is carried out by exchanging plural requests among the servers.
Incidentally, the requests necessary for one message from the user terminal are recognized as one transaction by keywords and the like included in the message. For example, it is assumed that following messages exist:    msg1a (TagA=10, . . . )    msg1b (TagA=10, . . . )    msg1c (TagA=10, TagB=X, . . . )    msg1d (TagB=X, . . . )
In such a case, because msg1a, msg1b and msg1c have the same tag TagA and the values of the TagA are the same, it is possible to recognize them as the messages relating to the same transaction. On the other hand, because msd1d does not have TagA, it is judged in this viewpoint that msd1d is not a message relating to the same transaction as that of msg1a and the like. However, because msd1d and msg1c have the common tag TagB and the values “X” of TagB are the same, it can be judged that msg1c and msd1d are messages relating to the same transaction. Thus, because a message group relating to TagA and a message group relating to TagB have an overlapping message, the aforementioned msg1a to msd1d can be identified as messages relating to the same transaction. In this application, it is presumed that such a technique to identifying messages relating to the same transaction already exists. Then, it is presumed that a transaction ID or data corresponding to the transaction ID such as keywords or a value of the tag is included in each message, and the belonging transaction is identified for each message by using the transaction ID or the data corresponding to the transaction ID. In this application, the transaction ID or the data corresponding to the transaction ID is generally called “transaction ID”. In the aforementioned example, the value “10” of TagA may be used as the transaction ID.
In order to monitor behaviors of such a system and/or analyze a request delay problem, a message binding processing is carried out. For example, in a case where two transactions exist and 6 messages a to f are included in the respective transactions, an order of the message appearance is not fixed as depicted in FIG. 2 (e.g. msg2d represents a fourth message in the transaction 2.). Namely, the messages belonging to two transactions do not appear separately, but are mixed, and the order of messages in one transaction may be exchanged. The message binding processing is a processing to group the messages as depicted in FIG. 2 into the respective transactions and further collect, for each transaction, the messages belonging to the transaction. Namely, as depicted in FIG. 3A, the messages msg1a to msg1f belonging to the transaction 1 are classified and collected, and as depicted in FIG. 3B, the messages msg2a to msg2f belonging to the transaction 2 are classified and collected.
Incidentally, in the distributed transaction processing system, a technique to hold data consistency when a recovery processing is failed in a processing side system exists. Specifically, a transaction allocation processor judges whether or not it is possible to process the transaction in this system to allocate the transaction to this system or other system, and the transaction execution controller controls the execution of the allocated transaction. A transaction processing controller issues a clear request of transfer information in mutual transfer information storage areas when the transaction is ended in the processing side system, and in order to guarantee a transaction processing when being activated again after the processing side system is down, a requester side system inquires the state of the transaction for the processing side system after the communication path is re-established, and re-transfers the transfer information, if necessary. However, any processing to mutually associate messages constituting a transaction is not carried out.
In addition, a technique to automatically carry out an appropriate processing for a failure exists. Specifically, flags corresponding to a normal completion and abnormal completion in a multiple processing execution state table stationed in a buffer memory are updated when starting execution of a user program in the first to n-th processing. In addition, a consecutive execution program has a function to set a time when the user would like to automatically recover, and always confirms the time by the system timer. At the set time, the consecutive execution program refers to the multiple processing execution state table. When the flag of the abnormal completion on the table is detected, the consecutive execution program identifies information of the abnormal completion to activate a recovery program and carry out an automatic recovery. Next, when the recovery program is completed, the flag of the abnormal completion in the multiple processing execution state table is written to the normal completion. In this technique, it is not possible to rapidly respond to the configuration change.
Because the processing load of the aforementioned message binding processing is high, parallelization may be considered. However, the simple parallelization has following problems.
For example, as depicted in FIG. 4, it is assumed that a message allocator allocates messages belonging to transactions 1 and 4 to a binding server 1 in charge of the transactions 1 and 4, messages belonging to transactions 3, 6 and 7 to a binding server 2 in charge of the transaction 3, 6, and 7, and messages belonging to transactions 2 and 5 to a binding server 3 in charge of the transaction 2 and 5. Here, when the binding server 3 is required to dynamically be stopped, the message allocator changes an allocation rule to allocate messages belonging to the transactions 2 and 5 to the binding server 1 or 2. However, msg2b, msg2c and msg5a held in the binding server 3 as depicted in FIG. 4 are discarded without being bound. Moreover, messages, which belong to the transactions 2 and 5 and appear after the allocation rule changed, are allocated to the binding server 1 or 2. However, the messages, which were allocated to the binding server 3 and were discarded, do not reach the binding servers 1 and 2 even if they wait receiving. Therefore, because of the time-out, the messages, which belong to the transactions 2 and 5 and appear after the allocation rule changed, will be discarded. Therefore, all of the messages belonging to the transactions 2 and 5 are discarded and are not used for the system analysis, because they are not complete.
In FIG. 4, an example of stopping the binding server is shown. However, similar situation occurs in the dynamic addition of the binding server. Namely, a case may occur, where the allocation rule in the message allocator is changed, and at least one of the binding servers is no longer responsible for the transaction for which the binding servers have been responsible. Then, a part of messages belonging to the transaction for which the binding servers are no longer responsible will be discarded because all of messages for the transaction are not completely received.
Thus, in order to carry out the message binding processing in parallel without leakage of the messages, it is necessary to allocate all messages for one transaction to one binding server. For this purpose, it is necessary to add or delete the binding server after stopping the entire system. This is not realistic. However, when dynamically stopping or adding the binding server without stopping the entire system, it is impossible to simply carry out the message binding processing without leakage of the messages during a predetermined period before and after the stopping or adding.